Skip to content

Upgrade to Gradle 9.4#20833

Merged
andrross merged 3 commits intoopensearch-project:mainfrom
andrross:upgrade-gradle-9.4
Mar 14, 2026
Merged

Upgrade to Gradle 9.4#20833
andrross merged 3 commits intoopensearch-project:mainfrom
andrross:upgrade-gradle-9.4

Conversation

@andrross
Copy link
Member

Check List

  • Functionality includes testing.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@andrross andrross requested a review from a team as a code owner March 10, 2026 23:35
@github-actions
Copy link
Contributor

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit c364704.

PathLineSeverityDescription
gradle/wrapper/gradle-wrapper.jar1highBinary Gradle wrapper JAR replaced without a traceable source change. The gradle-wrapper.jar is executed directly by the build system before any integrity checks run, making it a prime supply chain attack vector. The new binary should be independently verified against the official Gradle 9.4.0 release artifact (SHA256: verify via official Gradle distributions). A tampered wrapper JAR could silently exfiltrate credentials, environment variables, or secrets available during CI/CD execution.
gradle/wrapper/gradle-wrapper.properties8mediumThe distributionSha256Sum was updated alongside the version bump to 9.4.0. While this is expected for a legitimate upgrade, the provided checksum (b21468753cb43c167738ee04f10c706c46459cf8f8ae6ea132dc9ce589a261f2) should be independently confirmed against the official Gradle release page for gradle-9.4.0-all.zip. A mismatched or fabricated checksum combined with a tampered wrapper JAR (see above) would complete a supply chain compromise where the wrapper downloads and runs a malicious Gradle distribution.

The table above displays the top 10 most important findings.

Total: 2 | Critical: 0 | High: 1 | Medium: 1 | Low: 0


Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.


⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

@reta reta added skip-changelog skip-diff-analyzer Maintainer to skip code-diff-analyzer check, after reviewing issues in AI analysis. labels Mar 10, 2026
@github-actions
Copy link
Contributor

github-actions bot commented Mar 10, 2026

PR Reviewer Guide 🔍

(Review updated until commit f2b556b)

Here are some key observations to aid the review process:

🧪 No relevant tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ Recommended focus areas for review

Version Compatibility

Upgrading from Gradle 9.2.1 to 9.4.0 may introduce breaking changes. Verify that all build scripts, plugins, and dependencies are compatible with Gradle 9.4.0, especially any deprecated APIs that may have been removed.

distributionUrl=https\://services.gradle.org/distributions/gradle-9.4.0-all.zip
networkTimeout=10000
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionSha256Sum=b21468753cb43c167738ee04f10c706c46459cf8f8ae6ea132dc9ce589a261f2

@github-actions
Copy link
Contributor

❌ Gradle check result for c364704: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

❌ Gradle check result for c364704: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@andrross andrross force-pushed the upgrade-gradle-9.4 branch from c364704 to 72e5a11 Compare March 11, 2026 14:52
@github-actions
Copy link
Contributor

Persistent review updated to latest commit 72e5a11

@andrross
Copy link
Member Author

@reta I ran into failures with the previous version that used evaluationDependsOn. I went ahead and let kiro refactor how the agent artifacts were being consumed by the other projects. Here's the description:

Also replace the eager cross-project task reference to
:libs:agent-sm:agent with Gradle-idiomatic patterns:

  • Add a consumable agentDist configuration in the agent
    project that publishes the prepareAgent output directory
    as an artifact with a Category attribute.
  • Add a matching resolvable agent configuration in the
    distribution subprojects to consume it via normal
    dependency resolution.
  • Replace direct task references (project.prepareAgent,
    project.jar) with lazy alternatives: tasks.named() for
    task providers, lazy GStrings for deferred path
    resolution, and closure-based dependsOn.

This removes the need for an evaluationDependsOn call which forced
the agent project to be configured before the distribution
project, violating Gradle best practices around project
isolation and configuration-time coupling.

We'll see if this works...

@github-actions
Copy link
Contributor

❌ Gradle check result for 72e5a11: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@reta
Copy link
Contributor

reta commented Mar 11, 2026

@reta I ran into failures with the previous version that used evaluationDependsOn. I went ahead and let kiro refactor how the agent artifacts were being consumed by the other projects. Here's the description:

Thanks @andrross , I will check it a bit later today, sorry about that

@andrross andrross force-pushed the upgrade-gradle-9.4 branch from 72e5a11 to 929105f Compare March 11, 2026 16:43
@github-actions
Copy link
Contributor

Persistent review updated to latest commit 929105f

@github-actions
Copy link
Contributor

❌ Gradle check result for 929105f: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@andrross andrross force-pushed the upgrade-gradle-9.4 branch from 929105f to 5c2f141 Compare March 11, 2026 18:51
@github-actions
Copy link
Contributor

Persistent review updated to latest commit 5c2f141

@github-actions
Copy link
Contributor

❌ Gradle check result for 5c2f141: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Also replace the eager cross-project task reference to
:libs:agent-sm:agent with Gradle-idiomatic patterns:

- Add a consumable agentDist configuration in the agent
  project that publishes the prepareAgent output directory
  as an artifact with a Category attribute.
- Add a matching resolvable agent configuration in the
  distribution subprojects to consume it via normal
  dependency resolution.
- Replace direct task references (project.prepareAgent,
  project.jar) with lazy alternatives: tasks.named() for
  task providers, lazy GStrings for deferred path
  resolution, and closure-based dependsOn.

This removes the need for an evaluationDependsOn call which forced
the agent project to be configured before the distribution
project, violating Gradle best practices around project
isolation and configuration-time coupling.

Signed-off-by: Andrew Ross <andrross@amazon.com>
@andrross andrross force-pushed the upgrade-gradle-9.4 branch from 5c2f141 to 92705e1 Compare March 11, 2026 20:47
@github-actions
Copy link
Contributor

Persistent review updated to latest commit 92705e1

@reta
Copy link
Contributor

reta commented Mar 11, 2026

@reta I ran into failures with the previous version that used evaluationDependsOn. I went ahead and let kiro refactor how the agent artifacts were being consumed by the other projects. Here's the description:

Just looked at it, configuration would be an idiomatic approach indeed, thanks @andrross

@github-actions
Copy link
Contributor

❌ Gradle check result for 92705e1: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

❌ Gradle check result for 92705e1: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

❌ Gradle check result for 92705e1: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

❌ Gradle check result for 92705e1: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Contributor

✅ Gradle check result for 92705e1: SUCCESS

@codecov
Copy link

codecov bot commented Mar 12, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.34%. Comparing base (8f8f7b5) to head (f2b556b).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main   #20833      +/-   ##
============================================
+ Coverage     73.31%   73.34%   +0.02%     
- Complexity    72248    72268      +20     
============================================
  Files          5795     5795              
  Lines        330044   330056      +12     
  Branches      47641    47643       +2     
============================================
+ Hits         241975   242078     +103     
+ Misses        68609    68568      -41     
+ Partials      19460    19410      -50     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@andrross
Copy link
Member Author

@reta Can you take a look again when you have a few minutes. Not urgent. I ran into a few other failures and had to make some additional tweaks.

@github-actions
Copy link
Contributor

Persistent review updated to latest commit f580c32

@reta reta force-pushed the upgrade-gradle-9.4 branch from f580c32 to 64d5bfc Compare March 13, 2026 00:22
Signed-off-by: Andriy Redko <drreta@gmail.com>
@github-actions
Copy link
Contributor

Persistent review updated to latest commit 64d5bfc

@reta reta force-pushed the upgrade-gradle-9.4 branch from 64d5bfc to 2b13e2f Compare March 13, 2026 00:23
@github-actions
Copy link
Contributor

Persistent review updated to latest commit 2b13e2f

@github-actions
Copy link
Contributor

❌ Gradle check result for 2b13e2f: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Signed-off-by: Andrew Ross <andrross@amazon.com>
@github-actions
Copy link
Contributor

Persistent review updated to latest commit f2b556b

@github-actions
Copy link
Contributor

✅ Gradle check result for f2b556b: SUCCESS

@andrross andrross merged commit e52e135 into opensearch-project:main Mar 14, 2026
35 checks passed
@andrross andrross deleted the upgrade-gradle-9.4 branch March 14, 2026 00:55
shayush622 pushed a commit to shayush622/OpenSearch that referenced this pull request Mar 16, 2026
* Upgrade to Gradle 9.4

Also replace the eager cross-project task reference to
:libs:agent-sm:agent with Gradle-idiomatic patterns:

- Add a consumable agentDist configuration in the agent
  project that publishes the prepareAgent output directory
  as an artifact with a Category attribute.
- Add a matching resolvable agent configuration in the
  distribution subprojects to consume it via normal
  dependency resolution.
- Replace direct task references (project.prepareAgent,
  project.jar) with lazy alternatives: tasks.named() for
  task providers, lazy GStrings for deferred path
  resolution, and closure-based dependsOn.

This removes the need for an evaluationDependsOn call which forced
the agent project to be configured before the distribution
project, violating Gradle best practices around project
isolation and configuration-time coupling.

Signed-off-by: Andrew Ross <andrross@amazon.com>

* Refactor the agent wiring to use configurations

Signed-off-by: Andriy Redko <drreta@gmail.com>

* Use .singleFile and lazy evaluation for agentJar

Signed-off-by: Andrew Ross <andrross@amazon.com>

---------

Signed-off-by: Andrew Ross <andrross@amazon.com>
Signed-off-by: Andriy Redko <drreta@gmail.com>
Co-authored-by: Andriy Redko <drreta@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip-changelog skip-diff-analyzer Maintainer to skip code-diff-analyzer check, after reviewing issues in AI analysis.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants